<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!--

Design by Free CSS Templates
http://www.freecsstemplates.org
Released for free under a Creative Commons Attribution 2.5 License
-->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>SEng 466 Project Page</title>
<meta name="keywords" content="" />
<meta name="description" content="" />
<link href="../default.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="wrapper">

<?php include('../includes/header.php'); ?>

</div>

<!-- start page -->
<div id="page">
	<!-- start content -->
	<div id="content">
		<div class="post">

		<h1 class="title">Communications</h1>
			<img src="../images/base_and_remote.jpg"/>
			<p>This section outlines the main methods of communication that we are using in this project. We are using wireless communication between both of the Arduino Uno boards. We are using UART for communication between the basestation and the computer as well as between the remote Uno and the remote Mega board. Below is a brief introduction to programming the wireless radios and using UART.</p>

		<h1 class="title">Nordic Semi nRF24L01</h1>
			<p>We are using a 2.4 GHz wireless radio that has been used by passed classes with success. We are going to use the radios to create a base station as well as a remote station that will create a bidirectional link between our platform and the desktop computer. Neil has developped the driver for this radio and has documentation and sample code on the lab website. Initially Neil was worried that the code may not be compatible with the newer Uno boards. He told us that if his code didn't work there was another library available <a href="http://www.arduino.cc/playground/InterfacingWithHardware/Nrf24L01">(Mirf)</a> on the Arduino Playground we could try at our own risk.</p>

			<h2>Initial Testing</h2>
			<p>When we first got our hands on the radios we decided to use the code on the Arduin Playground. This was partly due to the fact that we weren't sure if Neil's driver would work and partly due to the limited setup needed to run the sample code that came with the library. The library is called Mirf and comes with an updated SPI folder containing some updated SPI code not found in the latest release of the Arduino IDE. We used some initial client/server code that would basically just send a ping from one board to another and print out the time it took to get a reply.</p>

			<h2>Wireless Gamepad Data with Mirf Library</h2>
			<p>To take this a step further we wanted to modify this basic code and start sending the gamepad data from one UNO to the other. We bread-boarded the two UNO boards with the radios and connected one to the lab desktop PC and connected the BlinkM LED to the other one. The remote station would be the one with the LED and would eventually be on the platform used to send control signals to the MEGA board. We reused our code that we used to read the gamepad data over UART from the python script, but placed it in a library we called UART with some other helpful UART functions.</p>
			<p>We modified the code and had the LED light up on the remote station signifying that we were receiving the correct byte of information from the base station. The only issue was that the LED was not staying lit, but flashing on and off. We spent a lot of time debugging the code trying to fix any timing issues (using a call to delay()). We couldn't get the code working how we needed it to work and made a decision to look into using Neil's code. There is a lot of documentation for his driver and we talked to other groups who seem to be using the radios with his code without issue.</p>

			<h2>Neil's Radio Driver</h2>
			<p>Neil setup a radio debug station that could be used to test if our radio code was working correctly with his driver. He setup a laptop and an Arduino board with a radio that ran some code that would receive messages and print them to a serial terminal. After a few hours of reading his documentation we were able to get one Uno board to send some debug packets to the debug station and have them output on the serial terminal. After managing this all we had to do was write some similar receiving code on the other Uno to test that we could communicate between both Uno boards.</p>

			<h2>Wireless Gamepad Data with Neil's Driver</h2>
			<p>After successfully getting two Uno to communicate wirelessly we now decided to attempt sending gamepad data again over the wireless connection. Using similar code structure to the code using the Mirf library we modified the remote station to light the LED red when the right analog stick was moved upwards on the gamepad and green when the left analog stick was moved upwards. This was working, but there still seemed to be some timing issues as the LED would flash repeatedly even if the joystick remained in an upward position. After printing the received data to serial we realized that the data signifying an upward movement of the analog stick was being received, but zeros were injected into the packet at specific intervals, causing the LED to turn off then on again when the correct data was received. We discovered that this was due to some code written in our UART library. Instead of waiting until for 18 bytes to be received by the base station, it was waiting for strictly more than 18 bytes of data. By changing this condition to less than or equal we solved the problem.</p>

			<h2>Wireless Control of the Platform Motors</h2>
			<p>To control the platform motors we are using the data from the two analog joysticks of the gamepad. Since the vertical axis of each of these joysticks is represented by a byte we can use this value (between -100 and 99) to adjust the PWM signal to the motor driver which will adjust the duty cycle of the DC motors. Since we are also sending an emergency stop command we have decided that our wireless message payload will be 4 bytes in size. This will allow for two bytes for the joystick position and one other byte for the button press for the emergency button. To modify this payload is quite easy using Neil's radio driver as his message size is 128 bytes, but can be less than that value.</p>


			<h1 class="title">UART</h1>
			<p>UART is a protocol which is essentially RS232 serial. It is used for interdevice communication. For example, the Arduino uses it to communicate with the PC for debugging and programming, but it can also be used for interdevice communication (Arduino to Arduino).

			It is asychronous, which means some handshaking must occur to ensure data reliability. This was designed and implemented specifically for this project. Basically, two bytes are added to every packet as a form of handshaking. In retrospect, these bytes should have been at the start and front of a packet, but are instead at the beginning of each packet.</p>

<br/>
		<p>The receiveing function is the most interesting. It looks for a packet of a certain size passed in the function call, and checks to see if the UART buffer contains at least that size, plus two for the preamble handshake. Then it proceeds to check if the first two bytes in the buffer are equal to the defined preamble. If they are, then it reads the expected size of the packet and stores it, then flushes the buffer. This will ensure we get fairly new data everytime. If the preamble check fails, then it will take the failed byte out of the buffer, and return 0. This function is utilized below in the main program loop below.</p>

<br/>
		<p>The worst case scenario is if the start of the UART buffer contains the second preamble byte but not the first. In that case, the function is called size+2 times before a packet is correctly received.

		The preamble code was a recent addition because during one branch of our project, one arduino was sending data as fast as it could to the other arduino. This would mean that while UARTreceive is running, the buffer was actively being filled. Then, when the buffer is flushed, the start of the buffer is out of sync. This wasn't an issue before because we were sending packets every 100 ms which is slow enough that the buffer was never flushed mid-packet.</p>
		</div>
	</div>

<?php include('../includes/sidebar.php'); ?>

<!-- end content -->
<div style="clear: both;">&nbsp;</div>
<!-- end page -->
</div>
</body>
</html>
